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Types-and-effects are type systems, which allow one to express general semantic properties and to 
statically reason about program's execution. They have been widely exploited to specify static ana- 
lyses, for example to track computational side effects, exceptions and communications in concurrent 
programs. In this paper we adopt abstract interpretation techniques to reconstruct (following the 
Cousot's methodology) a types-and-effects system developed to handle security problems of a multi- 
tier web language. Our reconstruction allows us to show that this types-and-effects system is not 
sound with respect to the semantics of the language. In addition, we correct the soundness issues in 
the analysis and systematically construct a correct analyser. 

1 Introduction 

Types-and-effects systems are a powerful extension of type systems which allows one to express general 
semantic properties and to statically reason about program's execution. The underlying idea is to refine 
the type information so as to express further intensional or extensional properties of the semantics of 
the program: in practice, they compute the type of each program's sentence and an approximate (but 
sound) description of its run-time behavior. Since they are defined over the well understood theory of 
type systems, they are an intuitive framework for specifying and for developing static analyses. Such 
systems were originally introduced in lfl2l to statically track side effects in languages that mix functional 
and imperative feature. However, they have been employed to control many other kinds of computa- 
tional effects and analyses, e.g. exceptions fl8l . region inference ll22ll and communications in concurrent 
programs [21 ]. Recently, they have been used in O to handle security issues in LINKS EJ. 

Links is a strict, typed, functional language for web applications. Its main feature is to be multi-tier, 
that is, it enables the developer to mix client, server and database source code by delegating the charge 
of code and data partitioning to the compiler: from a single source file the compiler generates code for 
the database back-end, for the web server and the client front-end, ensuring that all data is stored either 
in client or in database. In [2] Baltopoulos and Gordon have shown that storing unencrypted applica- 
tion data on the client opens Links to attacks that may expose secrets and modify control-flow and 
application data. In order to overcome these problems they have proposed a compilation strategy based 
on authenticated encryption^ and a types-and-effects system to enforce programs to satisfy a particular 
class of integrity constraints (event-based assertions). This types-and-effects system formalizes source 
level reasoning about Links programs and allows them to prove security properties by inspection of the 
source code. For the definition of this system they have followed a methodology characterized by trans- 
lating each Links expression to an expression of a concurrent A -calculus with refinement types [3 ]. This 
translation hides the properties of the analysis, and does not guarantee the soundness with respect to the 

1 a combination of secrecy and integrity protection obtained by encrypting together data and its hash. 
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semantics of the language. Hence, we decided to study the properties of this analysis by reconstructing 
it by abstract interpretation [11]. 

Abstract interpretation (6l 13 HI |H is a general theory for approximating the semantics of dynamic 
systems. The key idea behind abstract interpretation is that the description of the behavior of a sys- 
tem (at various levels of abstraction) is an approximation of its formal semantics. In static analysis this 
means that every property of a program can be observed in its semantics and computed as an approx- 
imation: the intuition is that the analysis can be systematically derived by throwing away superfluous 
information from the semantics. In practice, the approximated semantics (abstract semantics) is obtained 
from the standard one (called concrete) by substituting the actual (concrete) domain of computation and 
its basic semantic operations with abstract domain and abstract semantic operations, respectively. The 
basic idea is that the abstract domain is a representation of some properties of interest about concrete 
domain's values, while abstract operations simulate, over the abstract domain, the behavior of their con- 
crete counterparts. Hence the abstract semantics computes the properties of interest and the analysis 
algorithm corresponds to evaluating programs over the abstract domain. Since the abstract domain is a 
sound approximation of the concrete one, the analysis algorithm is correct with respect to the semantics 
by construction. 

Type systems (and corresponding type inference algorithms) have been reconstructed as a hierarchy 
of abstract interpretations by Cousot [5]. In order to reconstruct the types-and-effects analysis of LINKS 
we extend Cousot's methodology by defining an abstract domain able to express types augmented by 
effects. In this paper we give the following contributions: 

• we demonstrate that the analysis defined by Baltopoulos and Gordon is not sound: in fact, the 
expression get (Text ( "Hello!" )) is type-checked but it results in a run-time type error (Section 
& 

• we show how to fix this unsoundness issue (Section [3]) 

• we systematically derive an abstract semantics which represents a correct analyser (we have im- 
plemented it in OCaml HU) (Sections Hand [5]) 

In the next sections we first will sketch the type-and-effect system proposed for LINKS (Section 0, 
then we describe the ideas and the methodology underlying our reconstruction. 

2 Secure Compilation of Links 

Standard web applications have a multi-tier architecture: user interface, application logic and data ma- 
nagement are implemented over three different tiers. Each tier runs on a different computational environ- 
ment (web browser, web server and database respectively) characterized by its own language and its data 
representation. This heterogeneity gives rise to the problem of impedance mismatch [19]: because each 
language has its own data type, data exchanged between tiers of same application have a different rep- 
resentation. This problem complicates the development of web applications because programmers need 
to define routines to interchange and convert data. To solve this problem a new class of web languages 
(multi-tiers languages) have has been developed. These languages allow programmers to blend server, 
client and database source code and provide automatic mechanisms for the partition of the application 
over tiers. 

Links is a functional programming language for web applications that belongs to the class of multi- 
tiers languages. LINKS enables developers to mix client, server and database source code by delegating 
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the charge of code and data partitioning to the compiler: from a single source code the compiler generates 
code for the database back-end, for the server and for the client front-end. 

In this way LINKS overcomes the problem of impedance mismatch by abstracting details of a single 
tier and by supporting an unified programming model similar to the one used for GUI applications. To 
realize this cross-tier programming model LINKS exploits the mechanism of the web continuation ll23l . 
These continuations are implemented as closures (expression to be executed plus values of free variables) 
and are stored in HTML pages either as hidden fields of forms or as URL parameters. This approach 
gives rise to security risks since a malicious client may modify those closures to enforce unexpected 
computations on the server. 

In particular, Baltopoulos and Gordon in [2 ] have demonstrated that the approach adopted by LINKS 
of storing unencrypted data on the client is not secure because an attacker may violate the data secrecy, 
the data integrity and the control-flow integrity of the application. To overtake these problems they have 
proposed a secure implementation of LINKS that includes a compilation strategy based on authenticated 
encryption to protect the closures held in the browser and a types-and-effects system to enable source 
level reasoning about security of web applications. This secure implementation has been formalized for 
TinyLinks, a simple subset of Links. 

TinyLinks is a A -calculus augmented with XML values for representing web pages and annotation 
expressions for expressing safety properties. Its syntax is shown in Figure [T] HTML pages are values 
created by applying the data constructors Text and El em: the first one represents simple text in HTML 
document, the second one a generic tag element. To express links and forms exists two ad-hoc data 
constructors that contains suspended expressions H. href (E) is a link that, when clicked, evaluates the 
expression E. f orm([l 1 , . . . , l n ] , E) is a HTML form with a suspended computation (the expression E) 
which requires user input. The input is represented by labels [li, ... , l n ] that will contain the values in- 
serted in the input fields of the form. The evaluation of href and form can be accomplished by using the 
operators get and post, respectively H. The annotations event L and assert L have no computational 
meaning. They allow us to annotate TinyLinks programs with event-based assertions expressing sui- 
table safety properties. An expression is safe if whenever an assertion assert L occurs in the execution, 
there exists a previous occurrence of an event event L. 

Baltopoulus and Gordon have defined a dependent types-and-effects system to verify that each ex- 
pression of a program is safe. This system is specified by a set of inductively defined typing judgments. 
These judgments are of the form r; F h E (_ : T) { F' }, where r is the typing environment, F is the set 
of events which have occurred and are needed to safe evaluation of the expression E (precondition); T 
and F' are, respectively, the type of value and the set of events (post-condition) yielded by the execution 
of E. 

The typing rules for the operations get and post, for the annotations event and assert and for the 
function application are shown in Figure |2l Rule (T-Get) establishes that the type assigned to get is xml 
(that represent the type of a generic HTML tag) with empty effect, provided that V is another HTML tag. 
By (T-Post), the type of post expression is xml with empty effect, provided that the values associated 
with submission labels are strings and that U is a HTML tag. By (T-Event) event L has type unit and 
effect L, provided that the values in the event L have a type. Rule (T-Assert) is similar to (T-Event) 
except that requires L € F, that is the precondition of the judgment includes L. Rule (T-App) is typical 
for application and shows how the mechanism of the annotations works: the expression is type checked 
if only if the events in the precondition Fi of the function have occurred in F with same values. The 
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c :: = Unit | Zero | Succ | String 

| Nil | Cons | Tuple | Elem | Text 
g::=+ |-|*|/ 
L::=p(Vi,...,V n ) 
V,U::=x|c(V 1 ,...,V n )|href(E) 

| Ax t . ...,x n .E | form([l 1 , l n ] ,E) 
E :: = V | varx = Ei;E 2 | g(E 1; E 2 ) 

|V(U 1 ,...,U n )|post([l 1 =V 1) ...,l n 

| get(V) | event L | assert L 
switch(V){ 

, case c (xi, . . . ,x n ) — > Ei 

1 -^E 2 
} 

Figure 1: Syntax of TinyLinks 

events generated after application include the ones of the post-condition of U. 

We say that a web application E is safe if and only if there is a derivation within the types-and-effects 
system of the judgment 0;0 h E 4^ (_ : xml){}, meaning that E is a closed expression which requires no 
precondition and which yields a web page without generating further events. 

After the definition of typing rules, the standard methodology requires to state and prove the sound- 
ness theorem which guarantees the validity of the analysis with respect to the semantics of the lan- 
guage. Baltopoulus and Gordon adopt a different approach by translating each TinyLinks expres- 
sion to an expression of a concurrent A -calculus with refinement types. This translation hides the 
details and the properties of the defined types-and-effects system, in particular the soundness. For 
instance, the expression get(Text("Hello!")) is safe because a derivation exists for the judgment 
0;0 h get (Text ("Hello !")) <^ (_:xml){ }. However, we will show in the next section that the proposed 
types-and-effects system is not sound because, even if this expression is type checked, its evaluation re- 
sults in a run-time type error. 

3 A Denotational Semantics for TinyLinks 

In this paper we adopt the approach described by Cousot in [5]. We define a denotational semantics 
for TinyLinks, by considering it as an untyped A -calculus. Furthermore, since we deal with effects, 
we explicitly consider assertions of events. To this purpose we introduce a special environment {events 
environment) which will store occurred events. The semantics of assert q(Vi, ... ,V n ) will require 
checking that q is bound in this environment to values Vi, . . . , V n . If this check succeeds, the evaluation 
yields a Unit value, otherwise a "sentinel" value indicating an error. 

For the sake of simplicity, we restrict the values in an event to integers only. We will also assume that 
functions have a single argument and predicates in events are bound to a single value. Since we regard 
TinyLinks an untyped A -calculus, we define the semantics domain of values (Eval) as a recursive sum 
of epos, by using the inverse limit construction described in l24l . Each element of this sum represents a 
specific class of values. For instance, ^ is the set of integers; U and S are singletons of the unit value 
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„ „ i val 

r;FhV<S=xml 

(T-Get)- 



r;Fhget(V) =£(_:xml){ } 

r;FhVi ^string Vi € { 1. ... ,n} HFhU^xml 
(T-Post) 

r;Fhpost([(l 1 =V 1 ,...,l n = V n )],U)^(_:xml){ } 

Tho /v(F,L) Cdom(T) 

L = p(V 1 ,...,V n ) r^hVi^Tj Vi£{l,...,n} 
T; F h event L ^ (_ : unit) { L } 
rho /v(F,L) Qdomijr) LGF 

L = p(V 1 ,...,V n ) r^hVi^Tj V/g{l, ...,«} 
TiF h assert L % (_:unit){L} 



(T-Event)- 



(T- Assert) - 



r;FhU^T T=(x 1 :T 1 ,...,x n :T n ){F 1 }^T 2 {F 2 } /v(T) = 

HFhVi^Ti Vi€{l,...,B} F 1 [V 1 /x 1 ]...[V n /*JCF 

(T " A PP } 7T P 

r;FhU(Vi,... ,V n ) 4T 2 {F 2 [Vi/xi] ... [V n /x n ] } 

Figure 2: Some examples of rules specifying the type-and-effect system for the correspondences analysis. 

and the error value 0; EEnv — > Eval — > (Eval x EEnv), EEnv — > (Eval x EEnv) and EEnv — > [.Eva/] — > 
(Eva/ x EEnv) are the sets of the denotations of functions, links and forms, respectively. 

The environment (Env) is a function from identifier (We) to values (Eval). The events environment 
(EEnv) maps predicates (Pred) to pairs formed by an element of Dval and an element of Mark. Dval 
denotes values which can occur in an event 0. Mark is the state of an event: E indicates that the event 
has occurred, EA that has occurred and has been asserted, A that has only been asserted. 

We define two semantic functions J : VAL — > Env — > EEnv — > Eval for values and [—J : EXP — > 
Env — > EEnv — > (Eval x EEnv) for expressions. The semantics of values is straightforward, because we 
only need to construct the corresponding denotation. Some examples of semantic equation are shown 
in Figure [3] In the definition, we use injections into Eval (like Unit, Href, Fun), continuous semantic 
operators (like bindList) and a meta-language which includes: 

• ife\thene2elsees (conditional); 

• letx = e\ ine2 as a cleaner notation for ((Xx.e2)e\); 

• let*x = e\ ine2 for ((Xx.e2)* e\); 

• case e i ofin\ (x\ ) — > e2 - — ^ e^ for \kx\.e\, Xx2-e^, . .. , Xx2-e$]; 

• let(x\X2) = e\ ine2 for let y = e\ in let x\ = K\(y)letX2 = ^(j) in&%\ 

where 7T,-, [ — J , * and [—,...,—] are the standard operators for product, lifting and sum of epos ||26ll . 

The semantics of expressions is similar to the one of the untyped A -calculus. The most interesting 
cases of semantic equations are shown in Figure 0] and below we give some comments about them. 



4 this value is used to show a run-time type error 
5 in the following we will call them denotable values 
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r[Ax.E] P 

r[Href(E)]p0 
r[Form(ll,E)]p0 



[Fun(X(j)'.Xv. [Ejp[v/x] f )J 

[Form(X(f)'.Xvl.let* p' = bindList(p, 11, vl) in [Ejp'0')] 



Figure 3 



Examples of semantic equations for values. 



The semantics of get(V) asks to evaluate V; if the evaluation results into the denotation of a link 
(Href(f)), we evaluate the corresponding suspended expression (the closure /), otherwise we return an 
error value. 

The semantics of post(VL, V) is similar: if the evaluation of V is a form (Form(f)) and the evaluation 
of VL is a list of strings, we return the result of the application of the functional value / to the denotation 
of VL and to the current events environment 0. 

The semantics of event q(V) requires the evaluation of V; if the produced value is an integer, we 
create a new binding for the predicate q in and return a unit value otherwise we raise an error. 

The semantics of assert q(V) is similar, but requires the evaluation of V to be equal to the value 
bound to the predicate q in . In this case we update the state of the event in (j) and return a unit value. 

By using the semantic equation of get we prove that the evaluation of the expression get (Text ( 
"Hello!" )) results in a run-time type error (the value [WrongValueQ J) because the denotation of 
Text("Hello\") is not a link. Although a link is an XML value, it is different from other XML values 
because it is a special kind of functional abstraction. Notice that the type-and-effect system proposed for 
TinyLinks does not handle this special nature of links correctly, because it assigns the same type to the 
all XML values. Note that the same remark can be made for forms. Our above arguments demonstrate 
that the types-and-effects system of is unsound because exists an expression which is type checked 
but its evaluation yields yet a run-time type error. We argue that the solution to this problem is to use 
a type system with subtypes. For the sake of simplicity, in our reconstruction we will not use subtypes, 
but we will instead define two ad-hoc types for forms and links which will handled so as have a sound 
analysis. 

4 An Abstract Semantics for Inference of Types and Effects 

Following the classical methodology of abstract interpretation, once we have defined a concrete seman- 
tics, we need to define a collecting semantics by extending "V\— \ and \—\ to the powerset. 

The concrete semantics properties, which we are interested in, are the types and the event-based 
annotations. We need to define a suitable domain for both. One possibility is to define the abstract 
domain as the set of Hindley's monotypes (terms) with variables IPT51 ITOl l5l l20l [T3l. However, this 
is not possible, since types are annotated by effects. For example, a function type will have the form 
Ti { Fi } — > T 2 { F 2 }, where Fi are the events which have to be occurred before the function application, 
whereas F 2 are the events which we can consider occurred afterwards. Hence, we need to define a domain 
of annotated types. The main problem is that the algebra of annotated terms is not free. In fact, two types 
can be identified even if their syntax is different. For example, the types xml{ q(lO), p(l) } — > xml{ } 
and xml{ p(l), q(lO) } — > xml{ } have a different representation, but they are equal because the effects 
{ q(lO), p{\) } and { p(l), #(10) } denote the same set. Therefore, we cannot use a syntactic unification 
algorithm fPTll to solve equations between terms. 
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[get(V)Jp0 = let*V =nnp<!>in 
case v' of 

Href(f)^f<j> 

([WrongValueQ] , i) 
[post(VL, V)]p (j) = let* v' = y{V}p in 

let* V2 = checkStringList{map (Xx. y [xjp 0) VL) in 
case v' of 

Form(f) — > case V2 of 

V(vl)^fvl(j> 

([WrongValueQ J , l) 
{[WrongValueQ] , i) 
[event q(V)Jp = let* d = evalToDval(Y [Vjp (j)) in 
if d = dint(n) then 

(lUnitQ\,<j>[(d,E)/q\) 
else 

([WrongValueQ \ , l) 
[assert q(V)Jp0 = let* ev = evalToDval(V\V\p in 
let [ev' ,m) = <p q 
if ev = ev' then 

([Unit Q\,$[(ev',E A) /q]) 
else 

([WrongValueQ J , l) 
Figure 4: Examples of semantic equations for expressions. 

One solution would be to use an algorithm for unifying terms in non-free algebras (semantic unifica- 
tion). Such algorithms do exist HI, but they are not usable in practice. 

Our reconstruction does not rely on semantic unification but on another approach described in ll22l . 
This approach exploits special annotated types (simple types), where annotations are replaced by vari- 
ables (annotation variables), whose values have to satisfy some constraint. For example, the annotated 
type xml { q(lO), p(l) } — > xml { } becomes xml(a) — > xml(j6), where a and j3 are the minimal annota- 
tions A and B which satisfy the constraints A 2 { <?(10), p(l) } and B D { }, respectively. The algebra of 
simple types is free. Hence, the introduction of a new kind of variable in terms requires a simple variation 
of the unification algorithm: an annotation variable unifies with another annotation variable only. 

However, this solution is not completely adequate to define an abstract domain for the properties 
which we are concerned with, because the effects depend on the values. Hence we need to include 
them in the abstract domain. Since events in the precondition and post-condition of a function type may 
depend on the value bound to a formal parameter we need to remember it. We then introduce in the set 
of terms another kind of variables, called identifier variables. Identifier variables are handled by simple 
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modification of the unification algorithm: an identifier variable unifies with another identifier variable 
only. 

The domain of abstract values will contain also substitutions as in lfT3l . The role of substitutions 
can be explained as follows. At some point in the evaluation of the abstract semantics (for example, 
in the semantics of function abstraction), we will introduce new type variables, with the meaning "any 
possible type". During the evaluation (for example, of the function body), this information will be 
subject to instantiations, computed by unifications and represented as an idempotent substitution. Since 
the abstract semantic evaluation functions are defined by structural recursion, the easiest way to provide 
the instantiation information to the caller is to include it in the returned value. 

Although we have now all necessary information for defining an adequate abstract domain, there is 
a problem concerning the representation of effects in the constraints. Intuitively we can simply repre- 
sent them by using a set of pairs, where the first component is the predicate and the second one is the 
denotable value. The problem is in partial order, since we should consider both set inclusion and the 
relative precision of denotable values. We can achieve this by using power domains Ifl4ll24l . We use a 
different approach: we define an effect as a function from predicates to denotable values (we will name 
it correspondence function). We can then represent constraints by splitting them in two parts: the first 
part is a set of pairs (annotation variable, predicate) and the second one is a correspondence function. 

Let V t be a countable set of type variables, V a be a countable set of annotation variables, Ide be a 
countable set of identifier variable (V t n V a Hide = 0) and £ = {unit : 0, int : 0, string : 0,xml : I, link : 
I, form : I, list : I, fun : 5} U {tuple n : n | n > 2} be a numerable set of function symbol, T s is the set 
of terms with variables V ( uy a U Ide modulo renaming, ordered by the inverse instance relation. It is 
worth noting that we have introduced two new types form and link in order to solve the problem relating 
forms and links which we described in Section [3] Furthermore we will use annotation variables in xml, 
link, form and fun only; in fun there are two annotation variables representing the precondition and the 
post-condition respectively. We further assume that the first argument of fun is an identifier variable. 
We obtain TypeS by lifting T s with idempotent substitutions lfT3l and by adding a new bottom element 
Notype. 

As we described above, the first part of a constraint is a pair (annotation variable, predicate): (8, q) 
means that the predicate q is in the effect represented by the variable 8. We use inverse inclusion as partial 
order: if C\ is included in C%, then C\ has less information than C%, hence, its value is less precise. Let V a 
be the set of annotation variables and Pred be the set of predicates. We define Const r = p(V a x Pred). 
The second part of a constraint is a correspondence function whose domain is TPred = Pred — > Dval 
ordered by using the dual of usual partial order. We assume that cb: p(TPred) — > TPred is the gib 
operator and £ is the bottom element. 

The domain of abstract values is Type A = TypeS x Dval x Const r x TPred. In the following, we 
will denote by Error the bottom element of this domain. 

The domain of abstract environment (type environment) is AEnv = Ide — > Type A. We are now in 
the position to define our abstract domains AV = AEnv — > EEnv — > TypeA for values and AE = AEnv — > 
EEnv — > (TypeA x EEnv) for expressions. 

To relate the abstract domain to the concrete one we need to define a Galois connection. In ifTTTl we 
formally built this connection in in various steps, by using properly defined representation functions HTH 
and propositions. 

Some examples of abstract semantic equations are shown in Figures [5j [6] and [7] In these definitions, 
we assume to have a function mgu, which, given a set of term equations, computes a solution by using 
the unification algorithm. If there exists a solution, it returns the unifier S(6); otherwise, it returns F to 
denote failure. The set of equations is denoted by {t\ = t[, . . . , /„ = t' n }. Since idempotent substitutions 
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r[href(E)] fl p0 = 
7 G V cl fresh 

let((ts, _,C,/),f) = [Efp0m 

let A = assert (<j)', (j))in 

letE = event (<j>' ,<j>) in 

if E = d) Ats ^ NoType then 

casemgu({ts.t =xml(y) }Uts.9)of 
S{6)^let C' =CU{{y,q) \ qeA} 

let f' = cb{ /, eenvToT pred(dif ', 0)) } in 
((6(link(y)), 0), nodval, 0(C'), 6(f)) 
_ — > Error 

else 
Error 

r[Ax.E] fl P ^ = 

(X G V f 7i , 72 G V a fresh £ identity substitution 
let((ts, _,d,/i),f) = [Efp[((a,e),var(x),0, Q/x] 0in 
// ts ^ NoType then 
let § d = 0(0) 

Zef C' = { (71, g) | q G assert ((j)' , 0j) } m 
Zef C" = { (72, g) I g G event(ij)' , ^4) } m 
^ H = eenvToT pred(diff((j)' , fy)) in 
((6{fun(x, a, 71,^,72)), 0), 
raodra/, 0(CiUC'UC"), 0(cfc{/i, / 2 })) 

.Error 

Figure 5: The abstract semantics of links and functional abstractions. 

are isomorphic to solved form equations, we will use {t\ = t[, ...,t n = t' n } U to refer the union of 
equations in {t\ = t[ , . . . , t n = t' n } and equations defined by 0. For the sake of simplicity, the components 
of the elements of the domain TypeS, will be identified by a notation similar to the one used to access the 
fields of a structure in an imperative language. Given ts = (t', 0') G TypeS, then ts.t = t' and ts.O = 0'. 

Given an element C of Constr and a substitution 0, we will denote by 0(C) = {(0(5), /) | (8, 1) G C} 
the pair obtained by applying to all the annotation variables in C. 

Given a correspondence function / G TPred and a substitution , we define 6(f) = Xq.6(f q), where 
if d ^ var(x) for some x then (d) = d. 

Furthermore we assume that for / G TPred and C G Constr / 1 C and / C are the correspondence 
functions achieved by removing from / the predicates occurring and not occurring in C respectively; that 
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[get(V)fp0 = 
7 € V a fresh 

let (ts,d,C,f) =ym a p<\)in 
ifts ^ NoTypethen 

case mgu({ts.t = link(y) }Uts.d) of 
S(d) -> let C' = { (0(7), q) G 0(C) } in 
ifcheck(d(f G- C'), 0) Z/zera 
(((0(*mZ( 7 )), 0), 

wodraZ, 0(C) \C, 0(/|C)),0) 

eZse 

(Error, l) 
_ — )■ (Error, l) 

else 

(Error, l) 
[EiE 2 ]] fl p0 = 

x G Me <X\ G V f 71 , 72 € V a /res/i 
fcf ((/*!,_, Ci,/i),fr) =[E 1 ] fl p 
let((ts 2 ,d 2 ,C 2 ,f 2 ),<h) =[E 2 fp^ 
// Zsi ^ NoType A ZJ2 7^ NoType then 

case mgu({ts\.t = fun(x, a, 71, ZJ2-^ 72) }U 
U^i.0U^ 2 -0) 0/ 
5(0) -> Ze* C = { (5, G 0(Ci) I 5 G prvar(6(ts x .t)) } in 
letC" = {(S,q) G 0(Ci) | S G psvar(6(tsi.t))} in 
letf[ = 6(f l )[6(x),d 2 ]in 
ifcheck(d(f[ -G-C), 02 ) ^en 
(((0(^2-0= 0), T, 0(d UC 2 ) \ (Cue'), 

cb{6(f l ) I (C'UC"), 0(/ 2 ) }), incl(<k, (0(/O <-C'))) 

eZse 
(Error, l) 
_ — >■ (Error, l) 

else 

(Error, l) 

Figure 6: The abstract semantics of get expression and function application. 



f[x, d] for x G Ide, d G DVal and / G TPred is the correspondence function achieved by binding d to all 
predicates which are bound to var(x) in /; that given a / G TPred and G EEnv the function check(f, (j>) 
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returns true if the events represented by / have been occurred in (j), false otherwise; that for <j> G EEnv 
eenvToT Pred(fa is the correspondence function achieved from 0; that given fa,fa assert (fa, fa) is 
the set of predicates of events asserted in fa but not in fa, that event (fa, fa) is the set of predicates 
of events generated in fa but not in fa and that diff(fa, fa) is the events environment which contains 
the events of fa which are not in fa and the events of fa which changed their value or state in fa. 
Furthermore we assume that, given t G T s , prvar(t) and psvar(t) denote the set of annotation variables 
of t for preconditions and post-conditions, respectively. 



[assert q(V)fp0 = 

let (ts,d,C,f) = r[Vf p0in 
if ts 7^ NoType A (d = nint(n) V d = var(x)) then 
case mgu({ts.t = int } Uts.G) of 

5(0) — > if q £ dom(fa V TZ\(§(q)) = d then 

(((unit, d), nodval, 6(C), 6(f)), (j) [(d,A)/q]) 
else 

(Error, l) 
_ —7- (Error, l) 

else 

(Error, l) 
[event q(V)fp0 = 

let (ts, d,C,f) = r[V] a p0w 
if ts 7^ NoType A (d = nint(n) \/d = var(x)) then 
case mgu({ts.t = int } Uts.G) of 

S(d) -*ifq$. dom(fay <$>(q) = (d, T) then 

(((unit, d), nodval, d(C), 6(f)),(j>[(d,E)/q]) 
else 
(Error, l) 
_ — > (Error, l) 

else 

(Error, l) 



for some n € 3f , x € Ide and where T € { E, EA } 



Figure 7: The abstract semantics of event and assert annotations. 

The semantics of links consists in the evaluation of the expression E. If in this evaluation no errors 
(ts 7^ NoType) and no new events (this is required by the rule described in Section [2]) occur, then we 
check that the computed value has type xml. Since in our reconstruction xml, link and form are different 
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types without any relation, this check rejects all the expressions which return a value of type link or 
form. Although this behavior may seem too restrictive, because it rejects some legal expressions like 
href (href (Text("Hello"))), it guarantees us safety and simplicity in the management of these diffe- 
rent and unrelated types. If this check has success, we return an abstract value where the simple type is 
link and the constraint is risen by properly extending the result of the evaluation of E. 

The semantics of forms is similar. We evaluate E in a type environment where the labels 11 are bound 
to the abstract value with simple type string and constraint empty and we return an abstract value where 
the simple type is form. 

The semantics of functional abstraction consists in the evaluation of the body E in a type environment, 
where the formal parameter x is bound to a generic type. If in this evaluation no errors occur, we 
compute the events which are included in the precondition (represented by C' and fa) and in the post- 
condition (represented by C" and fa). We return an abstract value where the simple type is obtained by 
applying the substitution ts.d to the functional type (fun(x, a, Yi, ts.t, Yi)) and the constraint is obtained 
by combining C with C' and C" and / with fa. 

The semantics of get requires the evaluation of V to be successful and yields a value of type link. 
If the preconditions are satisfied, that is if they are in and have occurred before, we construct an 
abstract value where the simple type is xml and the constraint is obtained from the one returned by the 
evaluation of V by removing the information about preconditions. The pair which is returned has in 
the first component this abstract value and in the second one the events environment <p . This is correct 
because the semantics of href guarantees that no new events have occurred during the evaluation of the 
suspended expression. 

The semantics of post is similar except that we ask that the elements of list VL are strings and that 
the value yielded by the evaluation of V has type form. 

In the semantics of function application we evaluate the sub-expressions Ei and E 2 : if both evalua- 
tions do not produce errors, we check that the simple type of Ei is a function type where the argument 
has the simple type of E 2 and that the precondition of function is satisfied in the events environment 02 > 
obtained from evaluating both the sub-expressions. In order to perform this last check, we substitute the 
denotable value bound to x in fa by the one returned by the evaluation of E 2 . Then, by using the function 
check, we ask that the events required by the function body are in 02- If we succeed, we construct an 
abstract value where the simple type is 6(a) and the constraint is obtained by composing those returned 
by the evaluation of the sub-expressions, where the events of preconditions and post-conditions are re- 
moved. We return a pair composed by this abstract value and by the events environment 02 extended 
with the events of the post-condition of the function. 

The semantics of assert consists in the evaluation of V. If it yields an abstract value whose simple 
type is int and whose denotable value is a specific integer or a specific identifier, we check that there is in 
at most the same event which we are generating. In this way we are sure that it is impossible to change 
the value bound to a predicate. If this check has success, we build an abstract value where the simple 
type is unit and the constraint is the one returned by the evaluation of V. This abstract value is the first 
component of returned pair; the second component consists of the events environment extended with 
the new event. 

The semantics of event is similar except that we ask that, if the event is in (j), then its state has to be 
either E or EA. 
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5 Implementation and Examples 

Both the concrete and the abstract semantics have been implemented as OCaml lfl6l programs. The 
language provides a feature, the mechanism of functors, which allows us to have a unique semantic 
function (realised by the functor Semantics), parametrized with respect to the primitive operations and 
the semantic domain. We can thus construct the concrete semantics interpreter, which executes programs, 
and the abstract interpreter, which analyzes programs in terms of types and effects, by instantiating the 
same functor Semantics. 

Programs are represented in abstract syntax, although, for the sake of simplicity, we will use in the 
following LlNKS-like syntax. For example, the expression 

fun buy (value, dbpass) { 

var _ = assert Pricels (value) ; 
TextO'Hello") 

> 

defines a function which requires that the event Pricels (value) has occurred and which returns an 
XML value. The result of its evaluation by the abstract semantics interpreter is 
(type - : 

Function (_#value#varO_ , IntegerO, _annvarO_, 
Function (_#dbpass#varl_ , _typevarl_, _annvar2_, 

Xml (_annvar4_) , _annvar3_) , 
_annvarl_) 

No_dval [(_annvar2_, Pricels)] {Pricels -> _#value#varO_} , {}) 
meaning that the computed type is a function type whose first argument has a type integer and the se- 
cond one has type variable^ where the precondition (represented by the annotation variable _annvar2_) 
includes the event composed by the predicate Pricels and the value bound to the first formal parameter. 
If we give a value (for example 5) to the first parameter, the abstract semantics is 
(type - : 

Function (_#dbpass#var3_ , _typevar3_, _annvar7_, 
Xml (_annvar9_) , _annvar8_) 

Unknown [(_annvar7_, Pricels)] {Pricels -> 5}, {}) 
that is the computed type is a specialization of that one computed for buy where the predicate Pricels 
is bound to the value 5 in the precondition. The abstract semantics of the application of the function buy 
to 5 and "a" is an error 

Exception: No_type "apply_fun: no preconditions" 

because we are applying a function whose precondition is not satisfied. 

6 Conclusions 

We have described how to reconstruct a types-and-effects system, proposed to handle some security is- 
sues in Links, as an abstract interpretation of a denotational semantics which explicitly models the types 
and the effects. By our reconstruction we have precisely defined the relation between the semantics and 
the analysis, we have systematically constructed a correct analyser and we have shown that the proposed 
types-and-effects system was not sound. We have stressed that the unsoundness derived from the fact of 



6 since the dbpass parameter is not used in the body, the analyzer cannot compute a more precise type 
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considering forms and links as simple XML values forgetting their own differentiating features. In our 
reconstruction we have solved this problem by using two new specific types and we have managed them 
in ad-hoc manner. We plan to extend our reconstruction to consider a type system with sub-types so as 
to be able to manage links and forms in a more uniform and elegant way and to use additional values in 
the effects. 

One advantage of abstract interpretation approach on the type system approach is that the analysis 
is directly derived from the semantics and is sound by construction. This forces one to tackle from the 
very beginning subtle problems such as the ones described in Section[3]that might only be revealed while 
trying to prove the soundness theorem following the type system approach. On the other hand we have 
shown that abstract interpretation can easily handle extensions of types, such as types and effects. There 
is only one example in the literature of an abstract interpretation reconstruction of a type and effect static 
analysis [25]. 

References 

[1] F. Baader & J. H. Siekmann (1994): Unification theory. In Dov M. Gabbay, Christopher J. Hogger, J. A. 
Robinson & Jorg H. Siekmann, editors: Handbook of Logic in Artificial Intelligence and Logic Programming 
(2). Oxford University Press, pp. 41-126. 

[2] I. G. Baltopoulos & A. D. Gordon (2009): Secure Compilation of a Multi-Tier Web Language. In: TLDI '09: 
Proceedings of the 4th international workshop on Types in language design and implementation. ACM, New 
York, NY, USA, pp. 27-38, doi jlO . 1145/1481861 . 1481866[ 

[3] J. Bengtson, K. Bhargavan, C. Fournet, A. D. Gordon & S. Maffeis (2008): Refinement Types for Secure 
Implementations. In: Proceedings of the 2008 21st IEEE Computer Security Foundations Symposium. IEEE 
Computer Society, Washington, DC, USA, pp. 17-32, doi j 10 . 1109/CSF . 2008 . 27| Available at |http://| 
[portal. acm.org/citation.cf m?id =1380848 . 1381243} 

[4] Ezra Cooper, Sam Lindley, Philip Wadler & Jeremy Yallop (2007): Links: Web Programming Without Tiers. 
In Frank de Boer, Marcello Bonsangue, Susanne Graf & Willem-Paul de Roever, editors: Formal Methods 
for Components and Objects. Lecture Notes in Computer Science 4709, Springer Berlin / Heidelberg, pp. 
266-296, doi jlO . 1007/978- 3- 540- 74792- 5_ 12) 

[5] P. Cousot (1997): Types as Abstract Interpretations, invited paper. In: Conference Record of the Twenty- 
fourth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. ACM Press, 
New York, NY, Paris, France, pp. 316-331, doi: 1 . 1145/263699 . 2637441 

[6] P. Cousot & R. Cousot (1977): Abstract interpretation: a unified lattice model for static analysis of programs 
by construction or approximation offixpoints. In: Conference Record of the Fourth Annual ACM SIGPLAN- 
SIGACT Symposium on Principles of Programming Languages. ACM Press, New York, NY, Los Angeles, 
California, pp. 238-252, doi jlO . 1145/512950 .5129731 

[7] P. Cousot & R. Cousot (1979): Systematic design of program analysis frameworks. In: Conference Record 
of the Sixth Annual ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages. ACM 
Press, New York, NY, San Antonio, Texas, pp. 269-282, doi jlO . 1 145/567752 . 5677781 

[8] P. Cousot & R. Cousot (1992): Abstract Interpretation and Application to Logic Programs. Journal of Logic 
Programming 13(2-3), pp. 103-179, doi jlO . 1016/0743- 1066 (92) 90030-T1 

[9] P. Cousot & R. Cousot (1992): Abstract Interpretation Frameworks. Journal of Logic and Computation 2(4), 
pp. 51 1-547, doi jlO . 1093/logcom/2 .4.5111 

[10] L. Damas & R. Milner (1982): Principal type-schemes for functional programs. In: POPL '82: Proceedings 
of the 9th ACM SIGPLAN-SIGACT symposium on Principles of programming languages. ACM, New York, 
NY, USA, pp. 207-212, doi: 10 .1145/5821 53.5821761 



L. Galletta, G. Levi 



95 



[11] L. Galletta (2010): Una semantica astratta per Vinferenza dei tipi ed effetti in un linguaggio multi-tier. 
Master's thesis, Universita di Pisa. 

[12] D. K. Gifford & J. M. Lucassen (1986): Integrating functional and imperative programming. In: Proceedings 
of the 1986 ACM conference on LISP and functional programming. LFP '86, ACM, New York, NY, USA, 
pp. 28-38, doi jlO .1145/319838 . 319848[ 

[13] R. Gori & G. Levi (2002): An Experiment in Type Inference and Verification by Abstract Interpretation. In: 
VMCAI '02: Revised Papers from the Third International Workshop on Verification, Model Checking, and 
Abstract Interpretation. Springer- Verlag, London, UK, pp. 225-239, doi jlO . 1007/3-540-47813-2_16] 

[14] C. A. Gunter & D. S. Scott (1990): Semantic Domains, chapter 12, pp. 634-674. Handbook of Theoretical 
Computer Science, Elsevier Science. 

[15] R. Hindley (1969): The Principal Type-Scheme of an Object in Combinatory Logic. Transactions of the 
American Mathematical Society 146, pp. 29-60. 

[16] INRIA: The Caml Language. Available at |http: //caml . inria.fr . WWW publication. 

[17] J.-L. Lassez, M. J. Maher & K. Marriott (1988): Unification revisited. In: Foundations of deductive databases 
and logic programming. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, pp. 587-625. 

[18] X. Leroy & F. Pessaux (2000): Type-based analysis of uncaught exceptions. ACM Trans. Program. Lang. 
Syst. 22, pp. 340-377, doi jlO .1145/349214 . 349230| 

[19] E. Meijer, W. Schulte & G. Bierman (2003): Programming with circles, triangles and rectangles. In: In 
XML Conference and Exposition. 

[20] B. Monsuez (1992): Polymorphic Typing by Abstract Interpretation. In: Proceedings of the 12th Conference 
on Foundations of Software Technology and Theoretical Computer Science. Springer- Verlag, London, UK, 
pp. 217-228, doi jlO . 1007/3-540-56287-7_107| 

[21] F. Nielson & H. Nielson (1994): Constraints for polymorphic behaviours of concurrent ML. In Jean-Pierre 
Jouannaud, editor: Constraints in Computational Logics. Lecture Notes in Computer Science 845, Springer 
Berlin / Heidelberg, pp. 73-88, doi jlO . 1007/BFb0016845l 

[22] F. Nielson, H. Riis Nielson & C. Hankin (2005): Principles of Program Analysis, 1st ed. 1999. corr. 2nd 
printing, 1999 edition. Springer. 

[23] C. Queinnec (2000): The influence of browsers on evaluators or, continuations to program web servers. 

SIGPLANNot. 35, pp. 23-33, doi j 10 . 1 145/357766 . 3512431 
[24] D. Schmidt (1986): Denotational Semantics: A Methodology for Language Development. William C Brown 

Pub. 

[25] J. Vouillon & P. Jouvelot (1995): Type and Effect Systems via Abstract Interpretation. Available at |http : JJ\ 
[www . cri . ensmp . f r/ classement/doc/A-273 .pdf | 

[26] G. Winskel (1993): The Formal Semantics of Programming Languages. MIT Press. 



